Field of the Invention
The present invention relates to a user interface system (hereinafter referred to as a UI system). In general, but not exclusively, a UI system is a programming tool for permitting a program designer to adapt a program or a series of programming operations to a particular end use.
A UI system for measuring devices or data processing programs may be arranged to define the interaction between equipment and the programs which control that equipment in terms of functions which correspond to the operation of a keyboard or other data input devices, such as a mouse. Such input devices permit the user to indicate processes to be executed by the measuring devices or programs.
Those processes include data acquisition and/or data collection by the devices or programs. In one known UI system, as described in The Complete Hypercard Handbook, published by Bantam Books Inc., by D G Gooman (1987), the relationship between operations carried out by users and the processing performed by the program can be defined and changed without completing execution of the program. In addition, in order to increase the independence of the programming from the input/output devices, it is also known to convert the relationship between a physical input device and a logical input device which deals with the data from the physical input device, on the basis that the data is from a virtual logical input device. That conversion depends on the input data type, and an example is described in the document "International Standard ISO 7942, Information Processing System Computer Graphics-Graphical Kernel System (GKS) Function Description (August, 1958)".
In the UI system described above, character strings and graphics are displayed on a screen and the display areas are handled by segments with special meanings. These areas are called icons, buttons or fields (hereinafter referred to simply as icons). A user can move the cursor to the desired icon using an indicating device, such as a mouse, by operating the button or buttons on the mouse. This operation will be referred to as "clicking" the mouse. Such a UI system can respond to users' operations and execute the desired process defined in advance by the icon.
There are various ways of expressing the relationship between the operations carried out by the user and the devices or programs. FIG. 2 of the accompanying drawings shows a typical rule. The portion of the rule on the left side of the symbol (201) shown in FIG. 2 refers to the location from which the operation of the rule is specified and the location for specifying the process. Thus, an input device (i.e. the mouse) is shown at 202 and an input operation (clicking the mouse) is shown at 203. This operation calls for data acquisition which is the function of device or program.
Thus, based on the rule shown in FIG. 2, clicking the mouse (pushing down the mouse button) when associated with the icon invokes the function for data acquisition from the device or program. Such operation of clicking the mouse in relation to a specific icon will hereinafter be referred to as clicking that icon.
In a conventional UI system as described above, each operation by the user corresponds to one process only. Therefore, it becomes difficult to achieve a flexible UI system which can switch between one process and another, and operate those processes on the basis of the same operation by the user. In many cases, it is important to switch processes to be carried out by a specific user operation, in dependence on the programming situation.
An example of the problems involved in modifying a conventional UI construction will be discussed below with reference to a specific example.
Most UI systems are provided to end users as finished products which cannot be modified. However, in order to set up such user interfaces, modification may be required from a standard system, which modifications will depend on the scale and interests of the user, and on the user's demands and applications. FIG. 4 of the accompanying drawings shows an example of a UI system for data collection where the user can signal for data aqcquisition or data collection by clicking the icons 401, 402, respectively. In order to understand the modification of the program, consider the case where the intention is to move the icon corresponding to data acquisition 401 to the position shown in FIG. 5. Such movement will be performed by clicking the icon, and it can immediately be appreciated that clicking the icon must carry out two different functions. Thus, in one case, clicking the icon must cause the program to carry out the data acquisition function where the data collection program is running and in the other case, correponding to the case where the program is to be changed, clicking the icon must permit the icon display location to be shifted.
In conventional methods, only one such operation can be specified so that flexible use of an operation for various situations is impossible. The only known way of overcoming this is to provide a conditional branch in the programming, so that, depending on the specified condition, different processes can be carried out as indicated by FIG. 3 of the accompanying drawings. As shown therein, two modes can be specified, and by interchanging between those modes either data acquisition or editing of the program can be carried out. It is assumed that an if- statement is used to specify the conditional branch, and therefore a value for the mouse variable "mode" has to be set at different locations in the program. The displayed icon location can be moved so long as the mouse button is held down during cursor movement.
However, problems occur in the conventional use of conditional branches, as will be discussed below. In order to create an icon, it is usual to duplicate an existing item that has suitable attributes which can be used for the new icon, such as rules or a display format. This reduces the time for specifying such icons, and means that a new icon can share at least some attributes with the original icon. In order to achieve this, icons may be defined in terms of standard program "objects" which can be stored in a suitable library of such objects. In order to specify an icon, a standard object is retrieved from the library and modified in the desired way. That modified icon may then also be stored in the library. If a new icon is to be created, a stored object is extracted from the memory (which object may be one of the original ones or a modified one which has previously been created), and that object may then be further modified in order to achieve the desired characteristics of the new icon. With such a newly created icon, the attributes necessary for UI editing may be used unchanged, and other attributes for program execution must be modified. Thus, as discussed above, some of the attributes are obtained from a previously defined icon, which attributes are common to general icon processes, and other attributes which are specific to individual icons have to be defined separately so as to permit that attribute to be used when the icon is clicked.
This means that, in many cases, the processes carried out by an icon for program execution and for editing are defined by different users in different situations. Therefore, when these definitions exist in one standard rule or object, as in the conventional method, it becomes complicated to define or modify the attributes, and therefore it is more likely that mistakes will be made. In particular, if an object defining an icon contains a conditional operation, as discussed above, then each object containing that conditional step will have to be changed if it is necessary to modify the conditional operation. This will be true even if the change necessary is the same for each icon (and hence the same for each object, since, in each case, only a part of the conditional statement will usually be modified.
There is the further complication that, when a conditional branch is used in a conventional method, the size of the rule or object increases, and therefore complicated conditional branches must be produced. This makes for a large UI system which is very difficult to define and modify. Thus, these problems mean that a UI system in which the same operation can correctly be programmed to correspond to current situations cannot be fully achieved by conventional methods. In the above example, clicking the mouse can result in the execution of different program functions, but it is difficult to program the UI system to achieve this, and the need for conditional statements in each of the rules (objects) means that those rules have to be modified independently, and there is the strong liklihood of a mistake being made.